As described above, the present invention relates to handling of policy information. Such a handling is necessary in case a user would like to establish a session (e.g., a multimedia session) in which for the establishment additional information are required. Such additional information could be, for example, services required for the session, addresses of particular servers necessary for the session, information regarding handling of the session or whether the user is entitled to use the corresponding services necessary for the session. Moreover, also charging and/or billing information can be included.
The handling of policy information is carried out in a Policy Control Function (PDF). This is a logical policy decision element that uses standard IP (Internet Protocol) mechanisms to implement policy in the IP media layer. The PDF makes decisions in regard to network based IP policy using policy rules, and communicates these decisions to a GGSN (Gateway GPRS Support Node, GPRS=General Packet Radio Service), which serves the UE (user entity) of the user/subscriber. In detail, the decisions are communicated to a Policy Enforcement Point (PEP) located in the GGSN. This is a logical entity that enforces policy decisions made by the PDF. Between the GGSN and the PDF, a so-called Go interface is defined. Further details on PDF and policy control over Go interface can be found in ETSI TS 29 207 V5.0.0 (2002-06), for example.
In the following, a session authorization mechanism carried out on establishing a session is described briefly.
When a UE wishes to establish a session, it sends a set-up request (e.g., SIP INVITE) to the P-CSCF. This set-up request indicates e.g., the media streams to be used. The P-CSCF sends the necessary information to the PDF which makes a decision on the request, i.e., authorizes the session or does not authorize the decision. This decision is included in a response called “authorization token” which is subsequently used by the PDF in order to identify the session and the media it has authorized.
The P-CSCF sends a corresponding response to the UE which includes a description of the negotiated media together with the authorization token from the PDF. After this, the UE issues a request (for example, a PDP context activation) to reserve the resources necessary to provide a required QoS (Quality of Service) for the media stream. In this request, the authentication token from the PDF provided via the PDF and Flow Id(s) (flow identifier(s)) identifying the flow(s) on the PDP context are included.
The GGSN receives the reservation request and sends a policy decision request to the PDF in order to determine if the resource request should be allowed to proceed. Included in this request are the authentication token and the Flow Id(s) provided by the UE. The PDF uses this authorization token and the Flow Id(s) in order to correlate the request for resources with the media authorization previously provided to the P-CSCF. After this, the PDF sends a decision to the GGSN. Then, the GGSN sends a response to the UE indicating that the resource reservation is complete. Thus, the session can be started.
As to the function of the Authorization Token and the Flow Id(s), it is noted that in 3GPP R5, the Authorization Token and Flow Id(s) are used as binding information. The Authorization Token is also used to derive the IP address of the PDF storing the policy information.
In 3GPP (Third Generation Partnership Project) R5 (Release 5), the PDF is part of a P-CSCF (Proxy Call Session Control Function). The P-CSCF is a network element providing session management services (e.g., telephony call control).
In the next release, namely 3GPP R6, separating the PDF from the P-CSCF will be studied. That is, in such an environment, the PDF is independent from the P-CSCF, as described in 3GPP TR 23.917V0.4.10 (2002-12), for example. Therefore, a plurality of PDFs may be arranged, in order to handle policies for different kinds of sessions, for example.
It is possible that in the future there is a N-M relation between the P-CSCF and the PDF, i.e., that there is a plurality of P-CSCF and a plurality of PDF related to each other. This N-M relation is already in 3GPP R5 between the GGSN and the PDF. For the P-CSCF, this means that it could send session information to many PDFs. This could be done either on session basis e.g. by using a simple round-robin mechanism. Or then the P-CSCF could consider the load of the PDFs and could send session information to the least loaded PDF. As an alternative, the P-CSCF could also send session information on UE basis, e.g. so that information on all sessions of a UE would be sent to the same PDF. And yet as another alternative, session information of roaming UEs could be sent to certain PDFs, whereas session information of home UEs would be sent to other PDFs.
It is possible that in the future, the P-CSCF is served by one PDF and one PDF serves many P-CSCFs (1 to N relation). In that case, when the UE is served by many P-CSCFs for different application sessions, the same problems as described above may occur.
As described above, the PDF derives policy information from the received session information. If session information of a UE may reside in multiple PDFs, requesting policy information becomes more complex.